Interfacing source transformation AD with operator overloading libraries

Scientific applications are usually written in a single language such as C, C++, or a flavor of Fortran. Various algorithmic differentiation (AD) tools exist to differentiate these applications by using source transformation [1, 2, 3, 4] or operator-overloading [5, 6]. The language that an application is written in often dictates the approach and tool to be used for differentiation. Additionally, performance considerations, tool philosophy (recomputation vs. storage), and specific tool capabilities such as support for sparse Jacobians or fixed-point iterations may play a role in the tool that is ultimately used to differentiate an application. Operator overloading and source transformation have their own strengths and weaknesses. The most important feature of operator-overloading-based AD tools is that they can be used in software regardless of its design complexity. Many large simulation tools (e.g., ISSM [7], SU2 [8, 9]) have been successfully differentiated in this manner. One drawback, however, is the large amount of memory required to store the tool-specific internal representation of the computation in order to run it in the reverse mode. The execution speed also suffers because of low compiler optimization potential. Both problems do not occur in source transformation tools. However, such tools cannot handle runtime features of C++ such as object inheritance, polymorphism, and templating. Some scientific applications are coded in C++ but contain portions that are in C or are C like. Often, the global structure of the application is complex and requires the use of advanced C++ features, but the computationally intensive portions are C functions. In our previous work [10] we successfully demonstrated the interfacing of an application differentiated mainly by using operator overloading with a library that has been differentiated using source transformation. The implementation relies on the externally differentiated function feature of ADOL-C, where such functions have actually been differentiated by using ADIC. The interface works also well with Tapenade. We demonstrated that this mixed approach is able to amortize the memory requirement for the calculation of adjoints and Jacobians on two applications. By using both approaches in the same application wherever they are applicable and well suited, we were able to use the strengths of both approaches. In this work we demonstrate the inverse interface. Here, the global application structure is a straightforward pure C (or Fortran) implementation; however, certain library calls may internally use complicated C++ features. We have created an entirely new interface keeping in mind the features of both ADOL-C and ADIC to support this setup.